| blob | 7f07862b2d86bdc03e74ff363ec7ce2de4b497b2 |
3 <!--Converted with LaTeX2HTML 2002 (1.67)
4 original version by: Nikos Drakos, CBLU, University of Leeds
5 * revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
6 * with significant contributions from:
7 Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
8 <HTML>
9 <HEAD>
22 </HEAD>
24 <BODY >
26 <P>
35 </DIV>
40 </DIV>
42 Permission is granted to make and distribute verbatim or modified
43 copies of this specification provided that the terms of the GNU Free
46 <P>
47 <BR>
50 Contents</A>
51 </H2>
52 <!--Table of Contents-->
54 <UL>
57 <UL>
68 </UL>
69 <BR>
72 <UL>
101 </UL>
102 <BR>
105 <UL>
118 </UL>
119 <BR>
122 <UL>
129 </UL>
130 <BR>
133 <UL>
140 </UL>
141 <BR>
144 <UL>
151 </UL>
152 <BR>
157 <UL>
166 </UL>
167 <BR>
172 <UL>
193 </UL></UL>
194 <!--End of Table of Contents-->
195 <P>
199 </H1>
200 This document gives a specification of the Go Text Protocol (GTP),
201 version 2.
203 <P>
207 </H2>
209 <P>
210 The intention of GTP is to provide a flexible and easy to implement
211 communication protocol for go programs. The main purpose is to allow
212 two programs to play each other but it is also useful for regression
213 testing and communication with a GUI or a go server. Most use cases
214 require an external support program, but this can be shared between
215 all programs with GTP support.
217 <P>
221 </H2>
222 The Go Text Protocol was developed within the GNU Go project,
223 initially to create a framework for automated regression testing and
224 to simplify connecting the program to go servers. The first appearance
226 2.7.95. The first stable release of GNU Go with GTP support was GNU Go
228 for version 1 of the protocol. There is no good specification of GTP
229 version 1, however, and this document is intended to provide one for
230 version 2.
232 <P>
236 <BR>
237 1.3 Communication Model
238 </H2>
239 The protocol is asymmetric and involves two parties, which we call
240 controller and engine. The controller is typically some kind of
241 arbiter or relay and the engine is typically a go playing program. All
242 communication is initiated by the controller in form of commands, to
243 which the engine responds.
245 <P>
246 The communication channel is assumed to be free from errors (i.e.
247 those are handled at a lower level). Examples are UNIX pipes or TCP/IP
248 connections. The latter can also be established over an error prone
249 modem connection by using PPP (Point to Point Protocol) as a transport
250 layer.
252 <P>
256 </H2>
258 <OL>
259 <LI>Regression testing.
260 <BR>
261 controller (regression script) -- engine
262 <BR>
263 The controller sets up a board position and asks the engine to e.g.
264 generate a move.
266 <P>
267 </LI>
268 <LI>Human vs program.
269 <BR>
270 controller (GUI) -- engine
271 <BR>
272 The controller relays moves between the human and the engine and
273 asks the engine to generate moves.
275 <P>
276 </LI>
277 <LI>Program vs program with arbiter.
278 <BR>
280 <BR>
281 The controller relays moves between the two engines and alternately
282 asks the engines to generate moves. This involves two different GTP
283 channels, the first between the controller and engine 1, and the
284 second between the controller and engine 2. There is no direct
285 communication between the two engines. The controller dictates board
286 size, komi, etc.
288 <P>
289 </LI>
290 <LI>Program vs program without arbiter.
291 <BR>
292 The same as above except that engine 1 includes the controller
293 functionality and the first GTP link is shortcut.
295 <P>
296 </LI>
297 <LI>Connection between go server and program.
298 <BR>
299 go server -- controller (relay) -- engine
300 <BR>
301 The controller talks to a go server using whatever protocol is
302 needed and listens for match requests. When one arrives it accepts
303 it, starts the go engine and issues GTP commands to set up board
304 size, komi, etc. and if a game is restarted it also sets up the
305 position. Then it relays moves between the server and the engine and
306 asks the engine to generate new moves when it is in turn.
307 </LI>
308 </OL>
310 <P>
314 </H2>
316 In cases of incompleteness or unclarity in this specification, the
317 reference implementation decides the correct behaviour. Notice,
318 however, that any command available in GNU Go 3.4, but not included in
320 considered a private extension (see section
323 <P>
324 Temporary comment: GNU Go 3.4 is currently under development and GTP
325 version 2 has not yet been implemented in the development versions.
327 <P>
331 </H1>
333 <P>
337 <BR>
338 2.1 Character Set
339 </H2>
340 All messages exchanged in this protocol are to be considered as 8-bit
341 character sequences. Only characters in the US-ASCII character set
342 (ANSI X3.4-1986) are used for standardized commands and responses.
343 Other characters may be used in comments (section <A HREF="gtp2-spec.html#sec:comments">2.9</A>)
345 there is no preferred character set specified for those.
347 <P>
351 </H2>
353 following control characters have a specific meaning in the
354 protocol:
355 <BR>
356 <P>
360 </TR>
363 </TR>
366 </TR>
367 </TABLE>
368 <BR>
369 <P>
370 All other control characters must be discarded on input and should not
371 be used on output.
373 <P>
377 <BR>
378 2.3 Whitespace
379 </H2>
380 The following ASCII characters can be used to indicate whitespace in
381 the protocol:
382 <BR>
383 <P>
387 </TR>
390 </TR>
391 </TABLE>
392 <BR>
393 <P>
394 In the rest of the specification we use 'space' to denote a whitespace
395 character. On input this may be either a SPACE or a HT. On output only a
396 SPACE should be used.
398 <P>
402 <BR>
403 2.4 Newline Convention
404 </H2>
405 A newline is indicated by a single LF character. Any occurence of a CR
406 character must be discarded on input, both by the engine and the
407 controller. On output either LF or some combination of CR and LF can
410 <P>
414 </H2>
415 A command is exactly one line long, with the syntax
417 <P>
418 <PRE>
419 [id] command_name [arguments]
420 </PRE>
422 <P>
425 newline) gives the arguments of the command.
427 <P>
431 </H2>
432 If successful, the engine returns a response of the form
434 <P>
435 <PRE>
436 =[id] result
437 </PRE>
439 <P>
442 ending with two consecutive newlines.
444 <P>
448 </H2>
449 If unsuccessful, the engine returns a response of the form
451 <P>
452 <PRE>
453 ?[id] error_message
454 </PRE>
456 <P>
459 explanation for the failure, also ending with two consecutive
460 newlines.
462 <P>
466 <BR>
467 2.8 Timing
468 </H2>
469 There are no synchronization requirements between the controller and the
470 engine. The controller may send commands at any time, regardless of
471 whether it has obtained responses for previous commands. The engine may
472 send responses whenever they are ready. It must, however, respond to the
473 commands in the same order as they come in. The engine is allowed to
474 make pauses while sending a response.
476 <P>
480 <BR>
481 2.9 Comments
482 </H2>
483 Comments can be included in the command stream. All text between a
485 comments and should be discarded on input.
487 <P>
491 </H2>
492 Empty lines and lines with only whitespace sent by the controller must
493 be ignored by the engine. No response must be generated. Empty lines and
494 lines with only whitespace sent by the engine and occuring outside a
495 response must be ignored by the controller. Notice that pure comment
496 lines will appear as empty lines after the comment has been discarded.
498 <P>
502 <BR>
503 2.11 Board Coordinates
504 </H2>
505 Board intersections, in this document called vertices, are encoded by a
506 letter plus a number. On a 19x19 board the letters go from A to T,
508 from the bottom to the top. Thus the lower left corner is called A1, the
509 lower right corner T1, the upper left corner A19, and the upper right
510 corner T19. Smaller boards use the obvious subset of these coordinates.
511 Larger boards, up to 25x25, are handled by extending the letters with U
512 to Z as needed. Boards larger than 25x25 are not supported by the
513 protocol.
515 <P>
519 </H2>
520 An engine does not have to implement all commands listed in this
521 specification. In general, for an engine to be used with some specific
522 controller, it is only required that the engine understands exactly the
523 commands needed by that controller. To simplify this matching of
524 capabilities, there are two predefined protocol subsets called the
525 tournament and the regression subsets. There is also a small set of
526 commands required for all GTP supporting engines.
528 <P>
532 <BR>
533 2.13 Private Extensions
534 </H2>
535 The protocol is trivial to extend with new commands. Obviously there is
536 a risk for conflicts if multiple engines make incompatible private
537 extensions of the protocol or if an engine makes a private extension
538 which turns out to be incompatible with a future extension of the
539 standard protocol.
541 <P>
542 In order to avoid this problem, standard commands do not include the
545 sufficiently unique for the engine or controller in question, and
550 <P>
551 Engines are allowed to use private extensions without a dash in the
552 name, but then they do it at their own risk and must be prepared to
553 change if the name later becomes used for a standard command.
555 <P>
559 </H2>
560 If an engine for some reason, e.g. an internal error, finds itself in a
561 position where it cannot meaningfully continue the session, the correct
562 action is to just close the connection. This is also what typically will
563 happen if the program should happen to encounter an uncontrolled crash.
565 <P>
569 </H1>
573 <BR>
574 3.1 Preprocessing
575 </H2>
577 <P>
578 When a command string arrives to an engine, it is expected to perform
579 the following four operations before any further parsing takes place:
581 <OL>
583 control characters except for HT and LF.
584 </LI>
585 <LI>For each line with a hash sign (#), remove all text following and
586 including this character.
587 </LI>
589 </LI>
590 <LI>Discard any empty or white-space only lines.
591 </LI>
592 </OL>
594 <P>
595 When a response arrives to a controller, it is expected only to do steps
596 <A HREF="gtp2-spec.html#it:remove-control">1</A> and <A HREF="gtp2-spec.html#it:convert-ht">3</A> above.
598 <P>
599 Naturally an implementation does not have to actually do this
600 preprocessing as a separate step but may interleave it with other
601 parts of the parsing. For purposes of the following specifications,
602 though, the preprocessing is supposed to have been carried out in
603 full.
605 <P>
609 </H2>
611 <P>
615 <BR>
616 3.2.1 Simple Entities
617 </H3>
619 <UL>
621 <BR>
623 $0 <= x <=
624 2^{31} - 1$
625 -->
626 <IMG
632 <P>
633 </LI>
635 <BR>
637 bit IEEE 754 float.
639 <P>
640 </LI>
642 <BR>
644 characters. Strings are case sensitive.
646 <P>
647 </LI>
649 <BR>
652 the string ``pass''. Vertices are not case sensitive. Examples:
653 ``B13'', ``j11''.
655 <P>
656 </LI>
658 <BR>
660 white, or ``black'' or ``b'' to denote black. Colors are not case
661 sensitive.
663 <P>
664 </LI>
666 <BR>
671 <P>
672 </LI>
674 <BR>
676 </LI>
677 </UL>
679 <P>
683 <BR>
684 3.2.2 Compound Entities
685 </H3>
687 <P>
689 <UL>
691 <BR>
694 combination of simple entities. The construction can be generalized
695 to any fixed number of entities.
697 <P>
698 </LI>
700 <BR>
703 far. The list can have an arbitrary number of elements and goes on
704 until an LF is encountered.
706 <P>
707 </LI>
709 <BR>
715 <P>
716 </LI>
718 <BR>
721 far. The multiline list can have an arbitrary number of lines and
722 goes on until two consecutive LFs are encountered.
723 </LI>
724 </UL>
726 <P>
730 </H2>
731 A command has one of the syntaxes
733 <P>
734 <PRE>
735 id command_name arguments\n
736 id command_name\n
737 command_name arguments\n
738 command_name\n
739 </PRE>
741 <P>
743 <UL>
745 </LI>
747 </LI>
749 of entities, the composition of which varies with the command If
751 </LI>
752 </UL>
754 <P>
758 </H2>
759 A successful response has one of the syntaxes
761 <P>
762 <PRE>
763 =id response\n\n
764 =id\n\n
765 = response\n\n
766 =\n\n
767 </PRE>
769 <P>
771 <UL>
773 number as in the corresponding command. It may be omitted if and
774 only if it was omitted in the command.
775 </LI>
777 space or a single LF, the composition of which varies with the
778 command. The response may be empty.
779 </LI>
780 </UL>
782 <P>
786 </H2>
787 An unsuccessful response has one of the syntaxes
788 <PRE>
789 ?id error_message\n\n
790 ? error_message\n\n
791 </PRE>
793 <P>
795 <UL>
797 number as in the corresponding command. It may be omitted if and
798 only if it was omitted in the command.
799 </LI>
801 </LI>
802 </UL>
804 <P>
808 <BR>
809 3.6 Standard Error Messages
810 </H2>
812 <P>
813 If the engine receives an unknown or unimplemented command, use the
814 error message ``unknown command''. Some commands fail in certain cases
815 with standardized error messages. Those are listed in the command
817 failures the engine can freely choose error message.
819 <P>
823 </H1>
825 <P>
829 </H2>
831 <P>
832 The protocol supports both fixed placement of handicap stones and free
833 placement. The handicap stones are always black.
835 <P>
839 <BR>
840 4.1.1 Fixed Handicap Placement
841 </H3>
843 <P>
844 With fixed placement the handicap stones are set in predetermined
845 positions. The maximum number of fixed handicap stones varies with the
847 for the handicap stones are given by this table:
849 <P>
853 </TR>
856 </TR>
859 </TR>
862 </TR>
865 </TR>
868 </TR>
871 </TR>
874 </TR>
877 </TR>
878 </TABLE>
879 <BR>
880 <P>
881 The placement of handicap stones on other board sizes mirrors that of
882 19x19 with stones at a specific distance from the edges and on the
883 middle lines of the board, with the following caveats:
885 <P>
887 <UL>
889 line instead of on the fourth line.
890 </LI>
891 <LI>For boards of even size there is no middle line and therefore no
892 handicaps larger than 4.
893 </LI>
895 </LI>
897 </LI>
898 </UL>
900 <P>
901 More explicitly we obtain the following table:
903 <P>
908 </TR>
912 </TR>
916 </TR>
920 </TR>
924 </TR>
928 </TR>
932 </TR>
936 </TR>
940 </TR>
944 </TR>
948 </TR>
952 </TR>
956 </TR>
960 </TR>
964 </TR>
968 </TR>
972 </TR>
976 </TR>
980 </TR>
984 </TR>
988 </TR>
992 </TR>
996 </TR>
1000 </TR>
1004 </TR>
1005 </TABLE>
1006 <BR>
1007 <P>
1011 <BR>
1012 4.1.2 Free Handicap Placement
1013 </H3>
1015 <P>
1016 With free placement the handicap stones are set as chosen by the
1017 controller or by one of the engines (for normal tournament use the
1018 engine playing the black stones would make the choice). The smallest
1019 number of handicap stones is 2. The highest number is one less the
1020 number of vertices on the board. However, when the number of handicap
1021 stones becomes very high there is no benefit in additional stones.
1022 Therefore, when asked to choose handicap placement, an engine is
1023 allowed to return a smaller number of stones than requested. This
1024 provision should only be used if the requested number of stones is so
1025 high that a smaller number of stones is believed to guarantee that the
1026 engine cannot possibly lose against any opponent.
1028 <P>
1032 <BR>
1033 4.2 Time Handling
1034 </H2>
1036 <P>
1037 The protocol has support for Canadian byo yomi, including absolute
1038 time (no byo yomi) as a special case. Canadian byo yomi is
1039 characterized by the three parameters
1041 <UL>
1046 </LI>
1051 </LI>
1056 </LI>
1057 </UL>
1058 The semantics is that the clock is first set to <IMG
1062 engine has no requirements on the number of stones while this time is
1063 running. When it is up, the clock is reset to <IMG
1067 engine has to play <IMG
1074 have been played, the clock is reset to <IMG
1078 remaining time. Then the engine has to play another <IMG
1082 the time is up. This procedure repeats until the game is over. If an
1083 engine fails to play <IMG
1087 loses on time.
1089 <P>
1090 Setting <IMG
1094 Setting <IMG
1098 over, the engine loses on time. Setting <IMG
1105 limits.
1107 <P>
1111 <BR>
1112 4.3 Scoring
1113 </H2>
1115 <P>
1116 Depending on the exact choice of rules (see also section
1118 less complex. With a few exceptions it is critical to determine which
1119 stones are dead and which are alive. Sometimes it is also necessary to
1120 distinguish between life in seki and independent life.
1122 <P>
1123 This protocol provides two commands to query the engines about score
1124 and group status. They are both valid only when the game is finished.
1126 <P>
1128 opinion about the score. The result is returned as a string of the
1131 is of course the difference between the number of points for each
1132 player, including komi.
1134 <P>
1136 engine about the status of the stones. This command takes a string
1139 requested status. The list is organized with one string per line. If
1140 an engine cannot distinguish between life in seki and independent
1141 life, all those stones should be reported as alive.
1143 <P>
1144 The protocol does not include any support for resolving disagreement
1145 about status or score.
1147 <P>
1151 </H1>
1153 <P>
1157 <BR>
1158 5.1 State Variables
1159 </H2>
1161 <P>
1162 An engine is expected to keep track of the following state information:
1164 <P>
1166 <UL>
1167 <LI>board size
1168 </LI>
1169 <LI>board configuration
1170 </LI>
1171 <LI>number of captured stones of either color
1172 </LI>
1173 <LI>move history
1174 </LI>
1175 <LI>komi
1176 </LI>
1177 <LI>time settings
1178 </LI>
1179 </UL>
1181 <P>
1185 <BR>
1186 5.2 Default State
1187 </H2>
1189 <P>
1190 There is no default state for any state variable. When first started,
1191 the engine may set these as it likes. A controller which has some
1192 specific opinion about these values must set them explicitly with the
1193 appropriate commands, including clearing the board.
1195 <P>
1199 </H2>
1201 <P>
1202 The state is changed by certain commands, as specified in their
1203 description in section <A HREF="gtp2-spec.html#sec:commands">6</A>. State which is not explicitly
1204 modified must remain unchanged. A failed command must never change any
1205 state.
1207 <P>
1211 <BR>
1212 6 Commands
1213 </H1>
1217 </H2>
1218 All implementations are required to support the following commands:
1220 <P>
1221 <PRE>
1222 protocol_version
1223 name
1224 version
1225 known_command
1226 list_commands
1227 quit
1228 boardsize
1229 clear_board
1230 komi
1231 play
1232 genmove
1233 </PRE>
1235 <P>
1239 </H2>
1243 </H3>
1244 The tournament subset adds the commands:
1245 <PRE>
1246 fixed_handicap
1247 place_free_handicap
1248 set_free_handicap
1249 </PRE>
1251 <P>
1255 </H3>
1256 The regression subset adds the commands:
1257 <PRE>
1258 loadsgf
1259 reg_genmove
1260 </PRE>
1262 <P>
1266 <BR>
1267 6.3 List of All Commands
1268 </H2>
1270 <P>
1274 </H3>
1276 <P>
1278 <UL>
1283 </TR>
1286 </TR>
1289 </TR>
1292 </TR>
1295 </TR>
1298 </TR>
1299 </TABLE>
1301 <P>
1303 </LI>
1308 </TR>
1311 </TR>
1314 </TR>
1317 </TR>
1320 </TR>
1323 name does not include any version information, which is provided by
1325 </TR>
1326 </TABLE>
1328 <P>
1329 </LI>
1334 </TR>
1337 </TR>
1340 </TR>
1343 </TR>
1346 </TR>
1349 number should return the empty string.</TD>
1350 </TR>
1351 </TABLE>
1353 <P>
1354 </LI>
1359 </TR>
1362 </TR>
1365 </TR>
1368 </TR>
1371 engine, ``false'' otherwise</TD>
1372 </TR>
1375 </TR>
1378 and known but unimplemented ones. Do not declare a command
1379 as known if it is known not to work.</TD>
1380 </TR>
1381 </TABLE>
1383 <P>
1384 </LI>
1389 </TR>
1392 </TR>
1395 </TR>
1397 <TD ALIGN="LEFT" WIDTH="90%"><TT>string& commands</TT> - List of commands, one per row</TD>
1398 </TR>
1401 </TR>
1404 private extensions.</TD>
1405 </TR>
1406 </TABLE>
1408 <P>
1409 </LI>
1414 </TR>
1417 </TR>
1420 </TR>
1423 </TR>
1426 engine closes the connection. The controller must receive
1427 the response before the connection is closed on its side.</TD>
1428 </TR>
1429 </TABLE>
1430 </LI>
1431 </UL>
1433 <P>
1437 </H3>
1439 <UL>
1444 </TR>
1447 </TR>
1450 The board configuration, number of captured stones, and move
1451 history become arbitrary.</TD>
1452 </TR>
1455 </TR>
1458 size, fails with the error message
1460 </TR>
1464 implementations of GTP version 2. Thus the controller must
1466 Even if the new board size is the same as the old one,
1467 the board configuration becomes arbitrary.</TD>
1468 </TR>
1469 </TABLE>
1471 <P>
1472 </LI>
1477 </TR>
1480 reset to zero for both colors and the move history is reset
1481 to empty.</TD>
1482 </TR>
1485 </TR>
1488 </TR>
1491 </TR>
1492 </TABLE>
1494 <P>
1495 </LI>
1500 </TR>
1503 </TR>
1506 </TR>
1509 </TR>
1512 </TR>
1515 ridiculous.</TD>
1516 </TR>
1517 </TABLE>
1519 <P>
1520 </LI>
1525 </TR>
1528 </TR>
1532 </TR>
1535 </TR>
1538 handicap stones have been placed.</TD>
1539 </TR>
1542 </TR>
1546 valid number of handicap stones.
1548 history.</TD>
1549 </TR>
1550 </TABLE>
1552 <P>
1554 </LI>
1559 </TR>
1562 </TR>
1565 engine prefers. See also section
1567 </TR>
1570 </TR>
1573 handicap stones have been placed.</TD>
1574 </TR>
1577 empty, bad vertex list</TD>
1578 </TR>
1581 The engine may place fewer than the requested number of
1582 stones on the board under certain circumstances, as
1584 The controller can check this by
1585 counting the number of vertices in the response.
1587 history. Vertices must not be repeated or include ``pass''.</TD>
1588 </TR>
1589 </TABLE>
1591 <P>
1592 </LI>
1597 </TR>
1600 stones should be placed on the board.</TD>
1601 </TR>
1604 </TR>
1607 </TR>
1610 </TR>
1613 The list must have at least two elements and no more than
1614 the number of board vertices minus one.
1615 The engine must accept the handicap placement.
1617 history. Vertices must not be repeated or include ``pass''.</TD>
1618 </TR>
1619 </TABLE>
1620 </LI>
1621 </UL>
1623 <P>
1627 </H3>
1629 <UL>
1634 </TR>
1637 </TR>
1640 vertex. The number of captured stones is updated if needed
1641 and the move is added to the move history.</TD>
1642 </TR>
1645 </TR>
1649 </TR>
1652 illegal from the protocol point of view.</TD>
1653 </TR>
1654 </TABLE>
1656 <P>
1658 </LI>
1663 </TR>
1666 </TR>
1669 chooses. The number of captured stones is updated if needed
1670 and the move is added to the move history.</TD>
1671 </TR>
1674 </TR>
1680 played or the string ``resign''.</TD>
1681 </TR>
1684 </TR>
1687 be returned if the engine wants to pass. Use
1688 ``resign'' if you want to give up the game. The
1689 controller is allowed to use this command for either
1690 color, regardless who played the last move.</TD>
1691 </TR>
1692 </TABLE>
1694 <P>
1695 </LI>
1700 </TR>
1703 are reset to the state before the last move. The last move
1704 is removed from the move history.</TD>
1705 </TR>
1708 </TR>
1712 </TR>
1715 multiple times.
1716 The engine may fail to undo if the move history is empty or
1717 if the engine only maintains a partial move history, which
1718 has been exhausted by previous undos.
1719 It is never possible to undo handicap placements. Use
1720 clear_board if you want to start over.
1721 An engine which never is able to undo should not include
1722 this command among its known commands.</TD>
1723 </TR>
1724 </TABLE>
1725 </LI>
1726 </UL>
1728 <P>
1732 </H3>
1734 <UL>
1739 </TR>
1742 </TR>
1744 <TD ALIGN="LEFT" WIDTH="90%"><TT>int byo_yomi_time</TT> - Byo yomi time measured in seconds.</TD>
1745 </TR>
1747 <TD ALIGN="LEFT" WIDTH="90%"><TT>int byo_yomi_stones</TT> - Number of stones per byo yomi period.</TD>
1748 </TR>
1751 </TR>
1754 </TR>
1757 </TR>
1761 The engine must accept the requested values. This command
1762 gives no provision for negotiation of the time settings.</TD>
1763 </TR>
1764 </TABLE>
1766 <P>
1768 </LI>
1773 </TR>
1775 <TD ALIGN="LEFT" WIDTH="90%"><TT>color color</TT> - Color for which the information applies.</TD>
1776 </TR>
1779 </TR>
1782 </TR>
1785 </TR>
1788 </TR>
1791 </TR>
1795 </TR>
1796 </TABLE>
1798 <P>
1799 </LI>
1804 </TR>
1807 </TR>
1810 </TR>
1814 </TR>
1818 </TR>
1821 leave the command unimplemented.</TD>
1822 </TR>
1823 </TABLE>
1825 <P>
1826 </LI>
1831 </TR>
1834 </TR>
1837 </TR>
1840 </TR>
1842 <TD ALIGN="LEFT" WIDTH="90%"><TT>vertex*& stones</TT> - Stones with the requested status.</TD>
1843 </TR>
1846 </TR>
1848 <TD ALIGN="LEFT" WIDTH="90%">See section <A HREF="gtp2-spec.html#sec:scoring">4.3</A> for details.</TD>
1849 </TR>
1850 </TABLE>
1851 </LI>
1852 </UL>
1854 <P>
1858 <BR>
1859 6.3.5 Regression Commands
1860 </H3>
1862 <UL>
1867 </TR>
1870 </TR>
1873 </TR>
1876 the sgf file. Board configuration, number of
1877 captured stones, and move history are found by
1878 replaying the game record up to the position before
1880 </TR>
1883 </TR>
1886 read in because it is broken in some way, fails with
1888 </TR>
1891 the filename cannot include spaces, hash signs (#),
1892 or control characters. The command requires the
1893 controller and the engine to share file system, or at
1894 least that the controller has sufficient knowledge
1895 about the file system of the engine. If
1897 moves in the file, read until the end of the file.
1898 This command has no support for sgf files with
1899 variations or game collections.</TD>
1900 </TR>
1901 </TABLE>
1903 <P>
1904 </LI>
1909 </TR>
1912 </TR>
1915 </TR>
1918 </TR>
1924 want to play a move or the string ``resign''.</TD>
1925 </TR>
1928 </TR>
1931 does not play the generated move. It is also advisable
1932 to turn off any move randomization since that may
1933 cause meaningless regression fluctuations.</TD>
1934 </TR>
1935 </TABLE>
1936 </LI>
1937 </UL>
1939 <P>
1943 </H3>
1945 <UL>
1950 </TR>
1953 </TR>
1956 </TR>
1958 <TD ALIGN="LEFT" WIDTH="90%"><TT>string*& board</TT> - A diagram of the board position.</TD>
1959 </TR>
1962 </TR>
1965 however, required to place the coordinates as
1967 This command is only intended to help humans with
1968 debugging and the output should never need to be
1969 parsed by another program.</TD>
1970 </TR>
1971 </TABLE>
1972 </LI>
1973 </UL>
1975 <P>
1979 </H1>
1981 <P>
1985 </H1>
1987 <P>
1991 </H2>
1993 <OL>
1995 machine-machine communication. At the same time we want it to be
1996 reasonably human readable as well. There are two principal reasons
1997 for this. The first one is to make it easy to debug a protocol
1998 implementation or to find the error if the communication breaks
1999 down, e.g. if two engines involved in a game get their boards out
2000 of sync. The second reason is to make it easy to online issue GTP
2001 commands, or write scripts, for engine testing.
2003 <P>
2005 games though, even if it can be done for testing purposes.
2007 <P>
2008 </LI>
2009 <LI>The protocol intentionally does not include any negotiation
2010 options. The controller dictates everything and the engine has to
2011 comply, unless it is technically unable to, in which case it has to
2012 fail. While this to some extent limits the power of the protocol, it
2013 considerably simplifies implementation of both engines and
2014 controllers.
2016 <P>
2017 Arguably an engine could fail on purpose as some kind of attempt to
2018 force negotiation. This is not encouraged and is considered bad
2019 style. A controller has absolutely no obligation to try to work
2020 around such failures.
2021 </LI>
2022 </OL>
2024 <P>
2028 </H2>
2030 <P>
2032 <UL>
2034 <BR>
2035 That the controller initiates all communication does not imply that
2038 <P>
2039 </LI>
2041 <BR>
2043 control characters. ``Other characters'' refer to characters in the
2045 such as the ISO-8859-x series.
2047 <P>
2048 </LI>
2050 <BR>
2051 The requirement to accept both SPACE and HT but only produce SPACE
2052 applies to both engine and controller. The reason for this asymmetry
2053 is that SPACE is the preferred character but since it for some
2054 purposes can be convenient to write scripts of GTP commands manually
2055 in text files it is conceivable that an HT may occur occasionally.
2057 <P>
2058 </LI>
2060 <BR>
2061 The newline convention is easy to implement and allows
2062 interoperability between platforms using LF, CRLF, or LFCR to
2063 indicate newlines. It does not interoperate with the CR only
2064 convention used in text files on MacOS, prior to MacOS X. This is
2065 not expected to be a substantial problem.
2067 <P>
2068 </LI>
2070 <BR>
2071 While the communication channels are required to be free from
2072 errors, we do not assume that they are free from delays. For
2073 communication over the internet, random delays are a reality and it
2074 would be unrealistic not to take this into account.
2076 <P>
2077 </LI>
2079 <BR>
2080 Comments are mainly useful in regression test suites.
2082 <P>
2083 </LI>
2085 <BR>
2086 The choice of board coordinates is guided by design principle
2088 instead use a pair of integers is slightly easier for a machine to
2089 parse and does not impose any limitations on the maximum board size.
2090 However, the better human readibility of the chosen format is
2091 considered significant enough.
2093 <P>
2094 This coordinate convention is identical to the one used on IGS and
2095 many other go servers, and is also used in the specification of the
2096 Go Modem Protocol.
2098 <P>
2099 </LI>
2101 <BR>
2103 values. In practice it would suffice to restrict these to small
2104 integers and half-integers, but it is probably better to allow
2105 general floating point numbers anyway.
2107 <P>
2108 </LI>
2110 <BR>
2111 Since a list can only be stopped by an LF, an entity like
2113 be possible to tell the ints from the colors in this particular
2114 case.
2116 <P>
2120 <P>
2121 The multiline list construction cannot be used for commands since these
2122 are terminated by a single LF.
2124 <P>
2127 varying number of elements on each line.
2129 <P>
2130 </LI>
2131 <LI><B><A HREF="gtp2-spec.html#sec:standard-error-messages">3.6</A> Standard Error Messages</B>
2132 <BR>
2133 Failures can be divided into two classes. In the first class we have
2134 syntactically incorrect commands and other failures of the
2135 controller to follow the specification. In the second class we have
2136 technical limitations of the engine, which the controller cannot
2137 easily foresee in advance.
2139 <P>
2140 Only failures in the second class have standard error messages, on
2141 the assumption that these are the only ones the controller need to
2142 take action on. Failures in the first class indicate programming
2143 errors and will require debugging. Thus those error messages may
2144 freely be chosen to best help the debugging.
2146 <P>
2147 </LI>
2148 <LI><B><A HREF="gtp2-spec.html#sec:fixed-handicap-placement">4.1.1</A> Fixed Handicap Placement</B>
2149 <BR>
2150 This fixed handicap placement is compatible with the Go Modem
2151 Protocol and many go servers.
2153 <P>
2154 </LI>
2155 <LI><B><A HREF="gtp2-spec.html#sec:free-handicap-placement">4.1.2</A> Free Handicap Placement</B>
2156 <BR>
2157 Filling all vertices but one with handicap stones leave them in
2158 atari and is obviously not attractive for black. Moreover black has
2159 the trivial placement of half the number of stones in a chessboard
2160 pattern which leaves white without a single legal move. It is also
2161 possible to place a smaller number of stones than that so that white
2162 cannot possibly form a single living group. Thus there clearly
2163 exists thresholds above which it is not meaningful to add more
2164 stones.
2166 <P>
2167 With this in mind it is recommended that every engine has a
2169 for other board sizes. Extremely weak engines are recommended to
2170 provide handicap placements all the way up to the full chessboard
2171 pattern.
2173 <P>
2174 </LI>
2176 <BR>
2177 The controller is responsible for measuring time and deciding
2178 whether an engine has run out of time. The information given by the
2180 guide the engines about how fast they need to play.
2182 <P>
2183 </LI>
2185 <BR>
2186 With most rulesets scoring is difficult for computer programs. Only
2187 sophisticated engines can be expected to have reliable scoring while
2188 many engines probably will not implement the scoring commands at
2189 all. A controller is recommended to have external methods available
2190 to decide the winner (e.g. an independent trusted program or a
2191 human reviewer) but there is no reason to invoke them if both
2192 engines implement the scoring commands and agree about the result.
2194 <P>
2195 The format of the score string is identical to the RE property in
2196 SGF FF[4].
2198 <P>
2199 </LI>
2201 <BR>
2202 An engine which never uses some state for anything does not have to
2203 keep track of it just because it should. The point of the rule is
2204 that the engine is not allowed to suddenly change any state which it
2205 does use, unless instructed to.
2207 <P>
2208 </LI>
2210 <BR>
2211 It may seem natural to require e.g. an empty board when the engine
2212 is started. However, it can also be convenient to be able to start
2213 the engine with e.g. an sgf file already loaded.
2215 <P>
2216 </LI>
2218 <BR>
2219 GNU Go has a wide array of commands used in regression testing, such
2221 captured. However, except for simple move generation it is not at
2222 all clear to what extent such commands can be defined in ways which
2223 are meaningful across multiple programs. It is desired to increase
2224 the set of standard regression commands in future protocol
2225 revisions, but it must be done with care.
2227 <P>
2229 usually desirable to get consistent regression results. I.e. for a
2230 given position the same move should always be generated. In actual
2231 play it is useful to have a random variability between moves of
2232 similar value, in particular in the opening, to avoid playing too
2233 predictably.
2235 <P>
2236 </LI>
2237 </UL>
2239 <P>
2243 <BR>
2244 8.3 Missing Features
2245 </H2>
2247 <P>
2249 <OL>
2251 <BR>
2252 This version of the protocol has no provisions to specify what
2253 ruleset and/or scoring options to use. This is planned for future
2254 revisions but has been omitted here due to the complexity of the
2255 issue.
2257 <P>
2258 The reason why this is considered complex is that there are numerous
2259 rulesets (using the term loosely) such as Japanese, Chinese, AGA,
2260 Ing, IGS, and New Zealand, which differ with respect to one or more
2261 of ko rule, area or territory scoring, scoring of seki, legality of
2262 suicide, effect of handicap stones on scoring, and so on.
2264 <P>
2265 As a workaround this kind of information has to be passed through
2266 other channels than GTP, e.g. as command line options when starting
2267 the engine.
2269 <P>
2270 In practice this is not all that much of a problem since these
2271 settings rarely vary between games, e.g. within a tournament. Still
2272 it is desirable to have this functionality in the protocol, but it
2273 is worth waiting for a well thought through design of the commands.
2275 <P>
2276 </LI>
2278 <BR>
2279 GNU Go includes a large number of commands to query the board, e.g.
2280 list legal moves, find connected strings, count liberties, and so
2281 on. These can be useful when writing a ``stupid'' user interface
2282 which does not itself know anything about the board logic. They have
2283 been omitted from this specification mainly to keep it shorter and
2284 make it look less imposing. They are under consideration for
2285 inclusion in later revisions.
2286 </LI>
2287 </OL>
2289 <P>
2293 </H2>
2294 Anyone may use this protocol for any purpose without any restrictions.
2296 <P>
2298 according to the terms of the GNU Free Documentation License, included
2301 <P>
2302 While this in theory allows anyone to create modified protocol
2303 specifications, which could potentially lead to great chaos, that
2304 would benefit noone and we trust people not be that stupid.
2306 <P>
2307 The reason why we allow modification at all is to make sure that new
2308 authors can continue evolving the protocol if previous authors
2309 disappear, without having to rewrite everything from scratch.
2311 <P>
2312 People who want to use this protocol as a basis for development of
2313 some other protocol are most welcome to start from this protocol
2314 specification.
2316 <P>
2320 </H1>
2322 <P>
2326 <BR>
2327 10 GNU Free Documentation License
2328 </H1>
2330 <P>
2332 <BR>
2333 <P>
2335 <BR>
2337 <BR>
2338 Everyone is permitted to copy and distribute verbatim copies
2339 of this license document, but changing it is not allowed.
2341 <P>
2344 Preamble</A>
2345 </H2>
2347 <P>
2348 The purpose of this License is to make a manual, textbook, or other
2349 written document ``free'' in the sense of freedom: to assure everyone
2350 the effective freedom to copy and redistribute it, with or without
2351 modifying it, either commercially or noncommercially. Secondarily,
2352 this License preserves for the author and publisher a way to get
2353 credit for their work, while not being considered responsible for
2354 modifications made by others.
2356 <P>
2357 This License is a kind of ``copyleft'', which means that derivative
2358 works of the document must themselves be free in the same sense. It
2359 complements the GNU General Public License, which is a copyleft
2360 license designed for free software.
2362 <P>
2363 We have designed this License in order to use it for manuals for free
2364 software, because free software needs free documentation: a free
2365 program should come with manuals providing the same freedoms that the
2366 software does. But this License is not limited to software manuals;
2367 it can be used for any textual work, regardless of subject matter or
2368 whether it is published as a printed book. We recommend this License
2369 principally for works whose purpose is instruction or reference.
2371 <P>
2375 </H2>
2377 <P>
2378 This License applies to any manual or other work that contains a
2379 notice placed by the copyright holder saying it can be distributed
2380 under the terms of this License. The ``Document'', below, refers to any
2381 such manual or work. Any member of the public is a licensee, and is
2382 addressed as ``you''.
2384 <P>
2385 A ``Modified Version'' of the Document means any work containing the
2386 Document or a portion of it, either copied verbatim, or with
2387 modifications and/or translated into another language.
2389 <P>
2390 A ``Secondary Section'' is a named appendix or a front-matter section of
2391 the Document that deals exclusively with the relationship of the
2392 publishers or authors of the Document to the Document's overall subject
2393 (or to related matters) and contains nothing that could fall directly
2394 within that overall subject. (For example, if the Document is in part a
2395 textbook of mathematics, a Secondary Section may not explain any
2396 mathematics.) The relationship could be a matter of historical
2397 connection with the subject or with related matters, or of legal,
2398 commercial, philosophical, ethical or political position regarding
2399 them.
2401 <P>
2402 The ``Invariant Sections'' are certain Secondary Sections whose titles
2403 are designated, as being those of Invariant Sections, in the notice
2404 that says that the Document is released under this License.
2406 <P>
2407 The ``Cover Texts'' are certain short passages of text that are listed,
2408 as Front-Cover Texts or Back-Cover Texts, in the notice that says that
2409 the Document is released under this License.
2411 <P>
2412 A ``Transparent'' copy of the Document means a machine-readable copy,
2413 represented in a format whose specification is available to the
2414 general public, whose contents can be viewed and edited directly and
2415 straightforwardly with generic text editors or (for images composed of
2416 pixels) generic paint programs or (for drawings) some widely available
2417 drawing editor, and that is suitable for input to text formatters or
2418 for automatic translation to a variety of formats suitable for input
2419 to text formatters. A copy made in an otherwise Transparent file
2420 format whose markup has been designed to thwart or discourage
2421 subsequent modification by readers is not Transparent. A copy that is
2422 not ``Transparent'' is called ``Opaque''.
2424 <P>
2425 Examples of suitable formats for Transparent copies include plain
2426 ASCII without markup, Texinfo input format, L<SUP><SMALL>A</SMALL></SUP>T<SMALL>E</SMALL>X input format, SGML
2427 or XML using a publicly available DTD, and standard-conforming simple
2428 HTML designed for human modification. Opaque formats include
2429 PostScript, PDF, proprietary formats that can be read and edited only
2430 by proprietary word processors, SGML or XML for which the DTD and/or
2431 processing tools are not generally available, and the
2432 machine-generated HTML produced by some word processors for output
2433 purposes only.
2435 <P>
2436 The ``Title Page'' means, for a printed book, the title page itself,
2437 plus such following pages as are needed to hold, legibly, the material
2438 this License requires to appear in the title page. For works in
2439 formats which do not have any title page as such, ``Title Page'' means
2440 the text near the most prominent appearance of the work's title,
2441 preceding the beginning of the body of the text.
2443 <P>
2447 </H2>
2449 <P>
2450 You may copy and distribute the Document in any medium, either
2451 commercially or noncommercially, provided that this License, the
2452 copyright notices, and the license notice saying this License applies
2453 to the Document are reproduced in all copies, and that you add no other
2454 conditions whatsoever to those of this License. You may not use
2455 technical measures to obstruct or control the reading or further
2456 copying of the copies you make or distribute. However, you may accept
2457 compensation in exchange for copies. If you distribute a large enough
2458 number of copies you must also follow the conditions in section 3.
2460 <P>
2461 You may also lend copies, under the same conditions stated above, and
2462 you may publicly display copies.
2464 <P>
2468 </H2>
2470 <P>
2471 If you publish printed copies of the Document numbering more than 100,
2472 and the Document's license notice requires Cover Texts, you must enclose
2473 the copies in covers that carry, clearly and legibly, all these Cover
2474 Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
2475 the back cover. Both covers must also clearly and legibly identify
2476 you as the publisher of these copies. The front cover must present
2477 the full title with all words of the title equally prominent and
2478 visible. You may add other material on the covers in addition.
2479 Copying with changes limited to the covers, as long as they preserve
2480 the title of the Document and satisfy these conditions, can be treated
2481 as verbatim copying in other respects.
2483 <P>
2484 If the required texts for either cover are too voluminous to fit
2485 legibly, you should put the first ones listed (as many as fit
2486 reasonably) on the actual cover, and continue the rest onto adjacent
2487 pages.
2489 <P>
2490 If you publish or distribute Opaque copies of the Document numbering
2491 more than 100, you must either include a machine-readable Transparent
2492 copy along with each Opaque copy, or state in or with each Opaque copy
2493 a publicly-accessible computer-network location containing a complete
2494 Transparent copy of the Document, free of added material, which the
2495 general network-using public has access to download anonymously at no
2496 charge using public-standard network protocols. If you use the latter
2497 option, you must take reasonably prudent steps, when you begin
2498 distribution of Opaque copies in quantity, to ensure that this
2499 Transparent copy will remain thus accessible at the stated location
2500 until at least one year after the last time you distribute an Opaque
2501 copy (directly or through your agents or retailers) of that edition to
2502 the public.
2504 <P>
2505 It is requested, but not required, that you contact the authors of the
2506 Document well before redistributing any large number of copies, to give
2507 them a chance to provide you with an updated version of the Document.
2509 <P>
2513 </H2>
2515 <P>
2516 You may copy and distribute a Modified Version of the Document under
2518 the Modified Version under precisely this License, with the Modified
2519 Version filling the role of the Document, thus licensing distribution
2520 and modification of the Modified Version to whoever possesses a copy
2521 of it. In addition, you must do these things in the Modified Version:
2523 <P>
2525 <UL>
2526 <LI>Use in the Title Page (and on the covers, if any) a title distinct
2527 from that of the Document, and from those of previous versions
2528 (which should, if there were any, be listed in the History section
2529 of the Document). You may use the same title as a previous version
2530 if the original publisher of that version gives permission.
2531 </LI>
2532 <LI>List on the Title Page, as authors, one or more persons or entities
2533 responsible for authorship of the modifications in the Modified
2534 Version, together with at least five of the principal authors of the
2535 Document (all of its principal authors, if it has less than five).
2536 </LI>
2537 <LI>State on the Title page the name of the publisher of the
2538 Modified Version, as the publisher.
2539 </LI>
2540 <LI>Preserve all the copyright notices of the Document.
2541 </LI>
2542 <LI>Add an appropriate copyright notice for your modifications
2543 adjacent to the other copyright notices.
2544 </LI>
2545 <LI>Include, immediately after the copyright notices, a license notice
2546 giving the public permission to use the Modified Version under the
2547 terms of this License, in the form shown in the Addendum below.
2548 </LI>
2549 <LI>Preserve in that license notice the full lists of Invariant Sections
2550 and required Cover Texts given in the Document's license notice.
2551 </LI>
2552 <LI>Include an unaltered copy of this License.
2553 </LI>
2554 <LI>Preserve the section entitled ``History'', and its title, and add to
2555 it an item stating at least the title, year, new authors, and
2556 publisher of the Modified Version as given on the Title Page. If
2557 there is no section entitled ``History'' in the Document, create one
2558 stating the title, year, authors, and publisher of the Document as
2559 given on its Title Page, then add an item describing the Modified
2560 Version as stated in the previous sentence.
2561 </LI>
2562 <LI>Preserve the network location, if any, given in the Document for
2563 public access to a Transparent copy of the Document, and likewise
2564 the network locations given in the Document for previous versions
2565 it was based on. These may be placed in the ``History'' section.
2566 You may omit a network location for a work that was published at
2567 least four years before the Document itself, or if the original
2568 publisher of the version it refers to gives permission.
2569 </LI>
2570 <LI>In any section entitled ``Acknowledgements'' or ``Dedications'',
2571 preserve the section's title, and preserve in the section all the
2572 substance and tone of each of the contributor acknowledgements
2573 and/or dedications given therein.
2574 </LI>
2575 <LI>Preserve all the Invariant Sections of the Document,
2576 unaltered in their text and in their titles. Section numbers
2577 or the equivalent are not considered part of the section titles.
2578 </LI>
2579 <LI>Delete any section entitled ``Endorsements''. Such a section
2580 may not be included in the Modified Version.
2581 </LI>
2582 <LI>Do not retitle any existing section as ``Endorsements''
2583 or to conflict in title with any Invariant Section.
2585 <P>
2586 </LI>
2587 </UL>
2589 <P>
2590 If the Modified Version includes new front-matter sections or
2591 appendices that qualify as Secondary Sections and contain no material
2592 copied from the Document, you may at your option designate some or all
2593 of these sections as invariant. To do this, add their titles to the
2594 list of Invariant Sections in the Modified Version's license notice.
2595 These titles must be distinct from any other section titles.
2597 <P>
2598 You may add a section entitled ``Endorsements'', provided it contains
2599 nothing but endorsements of your Modified Version by various
2600 parties - for example, statements of peer review or that the text has
2601 been approved by an organization as the authoritative definition of a
2602 standard.
2604 <P>
2605 You may add a passage of up to five words as a Front-Cover Text, and a
2606 passage of up to 25 words as a Back-Cover Text, to the end of the list
2607 of Cover Texts in the Modified Version. Only one passage of
2608 Front-Cover Text and one of Back-Cover Text may be added by (or
2609 through arrangements made by) any one entity. If the Document already
2610 includes a cover text for the same cover, previously added by you or
2611 by arrangement made by the same entity you are acting on behalf of,
2612 you may not add another; but you may replace the old one, on explicit
2613 permission from the previous publisher that added the old one.
2615 <P>
2616 The author(s) and publisher(s) of the Document do not by this License
2617 give permission to use their names for publicity for or to assert or
2618 imply endorsement of any Modified Version.
2620 <P>
2624 </H2>
2626 <P>
2627 You may combine the Document with other documents released under this
2628 License, under the terms defined in section 4 above for modified
2629 versions, provided that you include in the combination all of the
2630 Invariant Sections of all of the original documents, unmodified, and
2631 list them all as Invariant Sections of your combined work in its
2632 license notice.
2634 <P>
2635 The combined work need only contain one copy of this License, and
2636 multiple identical Invariant Sections may be replaced with a single
2637 copy. If there are multiple Invariant Sections with the same name but
2638 different contents, make the title of each such section unique by
2639 adding at the end of it, in parentheses, the name of the original
2640 author or publisher of that section if known, or else a unique number.
2641 Make the same adjustment to the section titles in the list of
2642 Invariant Sections in the license notice of the combined work.
2644 <P>
2645 In the combination, you must combine any sections entitled ``History''
2646 in the various original documents, forming one section entitled
2647 ``History''; likewise combine any sections entitled ``Acknowledgements'',
2648 and any sections entitled ``Dedications''. You must delete all sections
2649 entitled ``Endorsements.''
2651 <P>
2655 </H2>
2657 <P>
2658 You may make a collection consisting of the Document and other documents
2659 released under this License, and replace the individual copies of this
2660 License in the various documents with a single copy that is included in
2661 the collection, provided that you follow the rules of this License for
2662 verbatim copying of each of the documents in all other respects.
2664 <P>
2665 You may extract a single document from such a collection, and distribute
2666 it individually under this License, provided you insert a copy of this
2667 License into the extracted document, and follow this License in all
2668 other respects regarding verbatim copying of that document.
2670 <P>
2674 </H2>
2676 <P>
2677 A compilation of the Document or its derivatives with other separate
2678 and independent documents or works, in or on a volume of a storage or
2679 distribution medium, does not as a whole count as a Modified Version
2680 of the Document, provided no compilation copyright is claimed for the
2681 compilation. Such a compilation is called an ``aggregate'', and this
2682 License does not apply to the other self-contained works thus compiled
2683 with the Document, on account of their being thus compiled, if they
2684 are not themselves derivative works of the Document.
2686 <P>
2687 If the Cover Text requirement of section 3 is applicable to these
2688 copies of the Document, then if the Document is less than one quarter
2689 of the entire aggregate, the Document's Cover Texts may be placed on
2690 covers that surround only the Document within the aggregate.
2691 Otherwise they must appear on covers around the whole aggregate.
2693 <P>
2697 </H2>
2699 <P>
2700 Translation is considered a kind of modification, so you may
2701 distribute translations of the Document under the terms of section 4.
2702 Replacing Invariant Sections with translations requires special
2703 permission from their copyright holders, but you may include
2704 translations of some or all Invariant Sections in addition to the
2705 original versions of these Invariant Sections. You may include a
2706 translation of this License provided that you also include the
2707 original English version of this License. In case of a disagreement
2708 between the translation and the original English version of this
2709 License, the original English version will prevail.
2711 <P>
2715 </H2>
2717 <P>
2718 You may not copy, modify, sublicense, or distribute the Document except
2719 as expressly provided for under this License. Any other attempt to
2720 copy, modify, sublicense or distribute the Document is void, and will
2721 automatically terminate your rights under this License. However,
2722 parties who have received copies, or rights, from you under this
2723 License will not have their licenses terminated so long as such
2724 parties remain in full compliance.
2726 <P>
2730 </H2>
2732 <P>
2733 The Free Software Foundation may publish new, revised versions
2734 of the GNU Free Documentation License from time to time. Such new
2735 versions will be similar in spirit to the present version, but may
2736 differ in detail to address new problems or concerns. See
2737 http://www.gnu.org/copyleft/.
2739 <P>
2740 Each version of the License is given a distinguishing version number.
2741 If the Document specifies that a particular numbered version of this
2742 License "or any later version" applies to it, you have the option of
2743 following the terms and conditions either of that specified version or
2744 of any later version that has been published (not as a draft) by the
2745 Free Software Foundation. If the Document does not specify a version
2746 number of this License, you may choose any version ever published (not
2747 as a draft) by the Free Software Foundation.
2749 <P>
2752 ADDENDUM: How to use this License for your documents</A>
2753 </H2>
2755 <P>
2756 To use this License in a document you have written, include a copy of
2757 the License in the document and put the following copyright and
2758 license notices just after the title page:
2760 <P>
2761 <P>
2763 Permission is granted to copy, distribute and/or modify this document
2764 under the terms of the GNU Free Documentation License, Version 1.1
2765 or any later version published by the Free Software Foundation;
2766 with the Invariant Sections being LIST THEIR TITLES, with the
2767 Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
2768 A copy of the license is included in the section entitled ``GNU
2769 Free Documentation License''.
2770 </BLOCKQUOTE>
2771 <P>
2773 <P>
2774 If you have no Invariant Sections, write ``with no Invariant Sections''
2775 instead of saying which ones are invariant. If you have no
2776 Front-Cover Texts, write ``no Front-Cover Texts'' instead of
2777 ``Front-Cover Texts being LIST''; likewise for Back-Cover Texts.
2779 <P>
2780 If your document contains nontrivial examples of program code, we
2781 recommend releasing these examples in parallel under your choice of
2782 free software license, such as the GNU General Public License,
2783 to permit their use in free software.
2785 <P>
2788 About this document ...</A>
2789 </H1>
2791 This document was generated using the
2792 <A HREF="http://www.latex2html.org/"><STRONG>LaTeX</STRONG>2<tt>HTML</tt></A> translator Version 2002 (1.67)
2793 <P>
2796 Computer Based Learning Unit, University of Leeds.
2797 <BR>
2800 Mathematics Department, Macquarie University, Sydney.
2801 <P>
2802 The command line arguments were: <BR>
2803 <STRONG>latex2html</STRONG> <TT>-split 0 -show_section_numbers -nonavigation gtp2-spec.tex</TT>
2804 <P>
2806 <BR><HR>
2807 <ADDRESS>
2808 Gunnar Farneback
2810 </ADDRESS>
2811 </BODY>
2812 </HTML>